CamelCamelCamel API Design Evaluation and Latency Budget

Introduction#

We'll analyze how the different non-functional requirements are fulfilled efficiently, even when they depend on other service providers.

Non-functional requirements#

The following section discusses how the non-functional requirements are met by the C3 API.

Availability #

The availability of the C3 service depends on whether the Amazon service is functioning. Though the Amazon service promises to be highly available, if it fails at any time, the C3 should opt for alternatives. The illustration below shows how the C3 service processes prefetched data to respond to the client after the failure of the Amazon service. As we saw in the previous lesson, the product service of C3 periodically updates its database from the PA-API. As a result, in most cases, when a user request arrives, C3 will have an updated response for the client even if Amazon fails to reply.

Reliability#

Reliable data is provided to the client as the requests are responded to with data directly from the Amazon service. The reliability of the data may be questioned if the response is provided from locally available data in case of failure of Amazon's service. However, such issues are rare and may be resolved through a simple retry in most cases. Further, to improve reliability, the frequency of fetching data from Amazon may be increased at the cost of increased communication. This may result in up-to-date results but suffer from issues like rate limiting on Amazon's API.

Scalability #

The scalability of our service is highly dependent on the service of Amazon and is subject to being restricted by it. In situations in which the requests quota of Amazon isn’t scaling (enhancing) well, the scalability of our service will be affected. One possible technique to overcome this problem is limiting client requests. Different techniques will be required to support the scaling of our services internally, such as horizontally and vertically scaling the service.

Low latency #

The latency of the C3 service can be high for some requests, such as search, due to synchronous communication. The clients sit back and wait until the service providers process their requests. This latency can be improved with the following steps:

• The C3 service intermittently acquires data from Amazon service (as per C3's current API quota with Amazon's service.) If periodic requests to Amazon's PA-API increase, then the client's search request can be tackled within the C3 service with up-to-date data. As the reliability section discusses, we can increase the request's frequency with multiple associated accounts and SQS queues.

• The C3 service uses a browser extension on top of the Amazon service. Doing so helps reduce latency greatly because a user can analyze and add products to the watch list directly without explicitly searching for it on the C3.

• Marketplaces like Amazon require vendors to provide high-quality images of their products. Image optimization techniques to reduce image size while fetching product data can help to reduce latency.

• Caching can also help to reduce latency because a response is provided from the cache for repetitive requests by a client.

Latency budget#

This section aims to estimate the response time for the requests of the C3 service. The response time of search requests will differ from others because of dependency between services. We'll analyze the processing time required to handle a request by synchronous services. After that, we'll estimate response time based on the varying data sizes.

Note: As discussed in the back-of-the-envelope latency calculations, the latency of the GET and POST requests are affected by two different parameters. In the case of GET, the average RTT remains the same regardless of the data size (due to the small request size), and the time to download the response varies by 0.4 ms per KB. Similarly, for POST requests, the RTT time changes with the data size by 1.15 ms per KB after the base RTT time, which was 260 ms.

Search#

Let's estimate the size of the request to search for a product:

• Request size: The size of the request is approximately 1 KB.

• Response size: Let's say the search query returns a response, and each response contains a single page with 20 products, each with a size of 1 KB. The total size would be 21 KB (20 KB for data and 1 KB for header).

We'll consider response size only because it affects the response time.

Response time: In the case of a search request, the processing time increases to incorporate communication time between C3's search service and Amazon's search service. The processing time is given in the following illustration:

In the illustration above:

• $4\ ms$ indicates the time of processing a request by each service.

• $70\ ms$ is $RTT_{get}$ of the request between the two services, since the connection is alive.

So, the total processing time will be $78\ ms$ in case of a search request. We'll now estimate the response time for the search request, as given below:

Adding product to watch list#

Let's also estimate the size of the request to add a product to the watch list:

• Request size: The estimated request size is approximately 2 KB based on the product details to be added to the watch list and a header.

• Response size: The response to the request for adding a product to the watch list is approximately 1 KB, including the header.

We'll consider request size only since it affects the response time.

Response time: In the case of adding a product to the watch list, only a single server processes the request, i.e., the pub-sub server. The response time is kept at minimum in that case and is estimated below:

Note: We've considered the two service providers residing within a region. The processing time increases if they are in distinct regions. Also, in the illustration above, GET represents the search request and POST represents adding a product to the watch list.

Summary#

We focused on designing a service to track real-time price drops of Amazon’s products. This design problem is a good example of synchronous communication between service providers. We examined the third-party service provider’s effects on technical design decisions due to compatibility. The message formats to communicate with the C3 service are explained as well. This chapter also demonstrates the communication patterns within Amazon. The message format of Amazon with a unique authentication method can be an important strategy for designing different services. This chapter summed up the information on the PA-API of Amazon that can be used for other services as well. The discussion on non-functional requirements highlights different ways to keep the service available and to lower the response time.